home *** CD-ROM | disk | FTP | other *** search
/ Aminet 7 / Aminet 7 - August 1995.iso / Aminet / docs / misc / ConcNews.lha / news / amiga.programming / comp.sys.amiga.programmer_9650_000055.msg < prev    next >
Encoding:
Text File  |  1994-11-27  |  2.5 KB  |  63 lines
  1. Newsgroups: comp.sys.amiga.programmer
  2. Path: dd.chalmers.se!news.chalmers.se!sunic!EU.net!howland.reston.ans.net!europa.eng.gtefsd.com!MathWorks.Com!news.duke.edu!concert!sas!mozart.unx.sas.com!walker
  3. From: walker@twix.unx.sas.com (Doug Walker)
  4. Subject: Re: Why does c.o clear BSS? It's not needed!!
  5. Originator: walker@twix.unx.sas.com
  6. Sender: news@unx.sas.com (Noter of Newsworthy Events)
  7. Message-ID: <CotF0I.HzJ@unx.sas.com>
  8. Date: Mon, 25 Apr 1994 12:36:18 GMT
  9. References:  <80012334@prox.stgt.sub.org>
  10. Nntp-Posting-Host: twix.unx.sas.com
  11. Organization: SAS Institute Inc.
  12. Lines: 50
  13.  
  14.  
  15. In article <80012334@prox.stgt.sub.org>, "Boris Folgmann" <Boris@prox.stgt.sub.org> writes:
  16. |> Why does c.o clear BSS? In the AutoDoc for InternalLoadSeg() you find:
  17. |> [...]
  18. |> Clears unused portions of Code and Data hunks (as well as BSS hunks).
  19. |> (This also applies to LoadSeg() and NewLoadSeg()).
  20. |> [...]
  21.  
  22. If you're talking about SAS/C's c.o, it clears memory because the OS didn't 
  23. do it until AmigaDOS 2.0.
  24.  
  25. |> BTW: Why don't place everything in one CODE hunk?
  26. |> 
  27. |> Assembler Example:
  28. |> 
  29. |> Start:  move.l (ReturnCode,pc),d0
  30. |>         rts
  31. |> 
  32. |> ReturnCode: dc.l        10
  33. |> Storage:    dx.l        5
  34.  
  35. For one thing, I don't see why it's an advantage to have everything in
  36. one CODE hunk.  However, that point aside, there are several reasons
  37. for having multiple hunks:
  38.  
  39.    1. If you have a NEAR data hunk, you can use 16-bit offsets relative
  40.       to register A4 instead of full 32-bit relocations.  You could use
  41.       PC-relative offsets in the code hunk, but you'd be limited to
  42.       32k for your program PLUS your data.  With a seperate near section,
  43.       you get 64k of near data independant of code size.  The 16-bit
  44.       offsets are faster and allow compiler-implemented reentrancy (cres.o).
  45.  
  46.    2. CHIP data obviously has to go into a seperate section.  You don't
  47.       want your code taking up CHIP memory.
  48.  
  49.    3. Putting the stuff in seperate sections reduces the size of any
  50.       one section; this means that in fragmented systems, you have a 
  51.       better chance of being able to load the program.  If you have a 
  52.       program with 300k of code and 200k of data, but your system only
  53.       has two 400k chunks available, a single hunk won't load; two 
  54.       hunks would load.
  55.  
  56. -- 
  57.   *****                    / walker@unx.sas.com
  58.  *|_o_o|\\     Doug Walker<  BIX, Portal: djwalker
  59.  *|. o.| ||                \ CompuServe: 71165,2274
  60.   | o  |//     
  61.   ====== 
  62. Any opinions expressed are mine, not those of SAS Institute, Inc.
  63.